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m 

Oo BACKGROUND 



[0001] The present disclosure relates generally to the use of computer-based 

knowledge acquisition systems, and specifically to the gathering, representing, and 



N processing of knowledge. 

yg [0002] Artificial intelligence has long been a goal for those who design and 

n 

f[ develop computer systems. The development of such intelligence is directed toward 
designing systems which "think". It is hoped that thinking systems will be able to 
adapt to new situations, new problems, and new forms of input. For example, one goal 
of artificial intelligence is to solve problems by providing previously unanticipated 
solutions. 



[0003] Under the broad umbrella of artificial intelligence, two main approaches 

have developed. The first approach, known as machine learning, is directed to 
developing computer systems with the ability to acquire knowledge on their own from 
observations or through instruction. The second approach, known as knowledge 
acquisition, is directed to developing computer systems in which the computers are 
"expert" in some area. This approach includes drawing knowledge from experts, 
encoding this knowledge for use in a computer system, and providing software 
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programs which use the encoded knowledge to develop solutions. Knowledge 
acquisition systems are generally developed using the combined effort of knowledge 
engineers and software engineers. The knowledge engineers and software engineers 
interview experts to gain knowledge, capture the knowledge, and encode the 
knowledge in a computer-usable format. Software may then be developed to utilize the 
encoded knowledge. This development process is undesirable for a number of reasons. 
For example, the process is often expensive, generally requires specialized training, is 
an inefficient use of the expert's time, and is frequently unsuccessful in producing 
useful knowledge or solutions. 

[0004] Therefore, it is desirable to develop improved knowledge acquisition 

techniques and applications. 

SUMMARY OF THE INVENTION 

[0005] A technical advance is provided by a novel system and process for 

enabling a user to utilize a plurality of knowledge acquisition approaches to find a 
solution to a task, where the knowledge acquisition approaches include a task-method- 
knowledge approach and a structure-behavior-function approach. In one embodiment, 
the process comprises defining the task by providing information specifying at least one 
input parameter, one output parameter, and an initial approach. The provided 
information is analyzed to determine whether to process the task using the task- 
method-knowledge approach or the structure-behavior-function approach based on the 
specified initial approach. The task is processed using the determined approach and 
the input parameter to achieve a solution. A determination is made as to whether the 
solution is correct by comparing the solution with the output parameter. 



[0006] In another embodiment, if the determined approach is the task-method- 

knowledge approach, the process includes searching a plurality of existing methods for 
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a method operable to provide at least a portion of the solution. If the method exists, it is 
selected. Alternatively, if the method does not exist, the method is defined. 

[0007] In yet another embodiment, if the determined approach is the structure- 

behavior-function approach, the process includes searching a plurality of existing 
models for a model operable to provide at least a portion of the solution. If the model 
exists, it is selected. Alternatively, if the model does not exist, it is defined. A plurality 
of existing behaviors are searched for a behavior applicable to the model. If the behavior 
exists, the behavior is selected, which associates the behavior with the model. If the 

Q behavior does not exist, the behavior is encoded into the model using the task-method- 

Sj knowledge approach. 

03 

Tj BRIEF DESCRIPTION OF THE DRAWINGS 

ui 

r B [0008] Fig. 1 illustrates a computer system on which a knowledge acquisition 

flJ system may be practiced. 

q [0009] Fig. 2 illustrates a TMK hierarchy of a task, methods, and subtasks. 

[0010] Fig. 3 illustrates an SBF table of structure, behavior, and function. 

[0011] Fig. 4 is a flowchart of a method for combining a TMK and an SBF 
approach. 

[0012] Fig. 5 illustrates a TMK hierarchy with an SBF table as a method. 

[0013] Fig. 6 illustrates an SBF table with a TMK hierarchy as a behavior. 

[0014] Fig. 7 illustrates TMK data stored in a collection of relational database 

tables. 

[0015] Fig. 8 illustrates SBF data stored in a collection of relational database 

tables. 
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DETAILED DESCRIPTION 

[0016] The present disclosure relates to the use of computer-based knowledge 

acquisition systems, and more specifically to the gathering, representing, and 
processing of knowledge. It is understood, however, that the following disclosure 
provides many different embodiments, or examples, for implementing different 
features. Specific examples of components and arrangements are described below to 
simplify the present disclosure. These are, of course, merely examples and are not 
intended to be limiting. In addition, the present disclosure may repeat reference 
numerals and/ or letters in the various examples. This repetition is for the purpose of 
simplicity and clarity and does not in itself dictate a relationship between the various 
embodiments and/ or configurations discussed. 

[0017] Referring now to Fig. 1, a computer system 100 is illustrated as a 

representative example of an operating environment for a knowledge acquisition 
system. The computer 100 includes a central processing unit ("CPU") 102, a memory 
unit 104, an input/ output ("I/O") device 106, and may include a network interface 108. 
The components 102, 104, 106, and 108 are interconnected by a bus system 110. It is 
understood that each of the listed components may actually represent several different 
components. For example, the CPU 102 may actually represent a multi-processor or a 
distributed processing system; the memory unit 104 may include different levels of 
cache memory, main memory, hard disks, and remote storage locations; and the I/O 
device 106 may include monitors, keyboards, and the like. In addition, the network 
interface 108 may be connectable to a network 112. One or more of the memory devices 
104 may contain data representing a programmed embodiment of a knowledge 
acquisition system, which may include a knowledge engine designed to process 
information. 



[0018] In operation, a user may enter information into the system 100 in response 

to a display shown by a program designed for a particular task. The user may retrieve, 
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review, modify, or enter new knowledge into the program until satisfied. The user may 
then define initial and desired values and parameters as input to the knowledge engine, 
which processes the knowledge to find a solution. If a solution is found, the results are 
displayed to the user. If a solution is not found, the user is informed and given an 
opportunity to make modifications to the parameters and repeat the process. 

[0019] Referring now generally to Figs. 2 and 3, two knowledge encoding 

approaches used in knowledge acquisition are illustrated. One approach (Fig. 2) 
utilizes a task-method-knowledge ("TMK") hierarchy that encodes problem-solving 
strategies in a hierarchy representing strategies developed by experts for specific 
problems. This approach began with research by Ashok Goel at the Georgia Institute of 
Ejj Technology in Atlanta, Georgia. 

a. : 

[0020] The other approach (Fig. 3) encodes knowledge about artifacts and objects 

:\ in terms of their structure, behaviors, and functions (and so named "SBF"), and 
RJ explicitly specifies the structure and function of a device or object and the internal 
vp behaviors that explain how the device works. The encoded knowledge may be used to 
jj perform high-level design tasks. For example, the knowledge may be applied to 

modify an existing design to obtain a device which performs specific desired functions. 

[0021] Referring now specifically to Fig. 2, a TMK hierarchy is illustrated by a 

tree of nodes 200. The tree 200 includes a task 210, which represents a high-level 
problem to be solved. In general, a TMK hierarchy may include any number of high- 
level task nodes. Methods 212, 214, and 216 represent three approaches to solving the 
task 210. Subtasks 218, 220, and 222 may provide input to method 212 as alternative 
approaches or as providing data that when combined with the data of the other 
subtasks satisfies method 212. Subtasks may themselves have methods which may 
have child subtasks, where the processing of a subtask involves the processing of 
associated subtasks. Similarly, subtasks 224 and 226 provide input to method 214. 
Method 216 has no subtasks and is typically called a "procedure", which is an atomic 
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method. An atomic method is a process which does not spawn subtasks and may be an 
algorithm, a database retrieval, a request for user information, or a similar process. In a 
similar fashion, method 228 solves subtask 222, having itself subtasks 230 and 232. The 
TMK hierarchy may be extended by adding additional methods having subtasks 
and/ or subtasks having methods or procedures. The hierarchy may be considered as 
"complete" when all end nodes ("leaves' 7 ) are procedures. 

[0022] The TMK hierarchy illustrated by the tree 200 utilizes "strategic" 

knowledge that applies the thought process of an expert to attack and solve a problem. 
Arriving at a solution may include identifying inputs to each of the tasks and 
identifying initial states, values, parameters, and knowledge. A knowledge engine 
utilizing the tree 200 begins at the main task and attempts to find a solution using the 
initial values and associated methods and procedures. If the problem is not solved 

111 

s directly, it may be broken down into subtasks. Each subtask is then processed to find a 

L-s. 

fy solution to that particular subtask. 

~j [0023] For example, the high-level task 210 may be to design a new device such 

H 5 as a toilet. The task 210 may include a specific goal or may be bounded by a set of 

parameters. For example, the task 210 may be to design a toilet using less water. In this 
way, the task 210 may be defined by one or more desired features or properties. This 
high-level task 210 may be associated with several possible methods 212-216 leading to 
a solution of providing the desired design. The method 212 may reach a solution by 
designing an original toilet, while the method 214 may involve modifying a current 
design. The method 216 may look at designs of related non-toilet devices (e.g., pumps) 
and ways to modify them into a toilet. Each method 212-216 may have inputs. 
Accordingly, the method 212 may have as inputs a number of standard toilet 
specifications for tank and pipe capacities or pipe diameters, both of which enable the 
designer to design an original toilet. The method 214 may have current designs as 
input, while the method 216 may have designs of non-toilet devices as input. Likewise, 
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each method 212-216 may include outputs. In the present illustration, the output is the 
solution of providing a new toilet design. 

[0024] Each method 212-216 may be further broken down into subtasks/ methods 

218-234. The output of each subtask/ method 218-234 may be the solution to the high- 
level task 210, input to a method, or input to another subtask. In the present 
illustration, the subtask 218 may design the tank. The subtask 220 may design the water 
flow through pipes and valves and may provide input to the subtask 218. The subtask 
222 may design the handle which activates the flush of the toilet. The method 228 and 
subtasks 230, 232 may provide additional input into the design of the handle in subtask 
222. The subtask 224 associated with the method 214, may be to find current toilet 
designs. This subtask may have methods (not shown) of using existing knowledge 
(e.g., the amount of water used by current designs) or may have several methods of 
acquiring the water use values (e.g., calculate from the size of a tank or lookup in a data 
base of device characteristics). The subtask 226 is to design a tank requiring less water 
and may be associated with a method 234 which determines how much water is needed 
to fill a tank. 

[0025] In this manner, the problem is solved within the TMK hierarchy by 

decomposing the high-level task into methods and procedures which solve the 
problem, or by spawning subtasks which solve the problem or provide information 
needed by another task, subtask, or method. 

[0026] TMK knowledge bases may be used to solve substantial problems. For 

example, they may analyze economic indicators or census data, invest in stock markets, 
predict the results of elections, diagnose disease, prescribe medicine, produce tax 
returns, and perform a variety of other complex tasks. TMK knowledge bases are 
applicable to problems which use expert knowledge to strategically find solutions by 
decomposing problems into smaller problems which are iteratively decomposed and 
solved. 
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[0027] However, TMK hierarchies do not provide artifact knowledge (e.g., 

information about specific instances of models). In the above example, the goal of 
subtask 226 is to design a tank requiring less water, and while it may be decomposed 
further to define the strategic methods to accomplish this goal, TMK does not avail itself 
of the details of the newly designed tank (e.g., dimensions, materials, fluids and their 
flow through the device). Using TMK alone, the solution to subtask 226 requires 
specific and customized programming or other means for determining the size of the 
newly designed tank. 



[0028] Referring now specifically to Fig. 3, an SBF artifact is illustrated as a table 

300, although a state machine may be utilized to identify the components, substances, 
and connections, as well as the flow of substances through defined connections between 

%j components. SBF knowledge bases which include such artifacts may be used for device 

if! 

and object structure, behavior, and function. Once entered, this knowledge may be 
Jf; used to examine the design of the models in order to perform such functions as 
h* improving or modify the designs. Additionally, the knowledge may be used to design 
□ an entirely new model. In contrast to TMK, which focuses on a task driven approach to 

solving a problem using known techniques, SBF organizes and makes available 

information. 

[0029] An artifact is defined in terms of structure, behavior, and function. SBF 

knowledge has input and output values. To find a solution for an SBF knowledge set, 
known inputs and desired outputs are declared and the state machine tables are solved 
for the desired outputs. Generally, SBF knowledge is divided into "models" and 
"instances". A model is a template into which values are placed, while an instance is a 
set of values for a model. Accordingly, the inputs are desired values for a model and 
the outputs are instances which meet the specified input values. The inputs may 
comprise a structure, behavior, function, or a combination of these. The outputs would 
be instances which have the specified values. 
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[0030] 



For example, consider a knowledge base of toilets. There are a large 



number of toilet designs which may be divided into a number of different categories. 
For example, toilets may be distinguishable as intended for home use or for use in 
remote locations. Alternatively, they may be stationary versus portable. As illustrated 
in Fig. 3, a specific toilet may be described in terms of its structure 310 (size, 
components, etc.), behaviors 312 (flush, fill, etc.), and functions 314 (press handle, clean 
tank, etc.). 

[0031] Accordingly, the knowledge embodied in the SBF knowledge base could 

be used to design a toilet having specific properties. For example, suppose a designer 
wanted to design a toilet which uses 40% less water. The designer may use the 
knowledge base by retrieving (through special purpose software) existing toilets having 
desired structures, behaviors, functions, or a combination of these. 

[0032] For example, the designer might request a list of all toilet designs having a 

particular tank capacity or having water flow rates within a given range. The list of 
toilets matching the defined criteria would be provided to the designer, who could then 
make modifications to arrive at a design of the desired specifications. This new toilet 
could be added to the knowledge base for use in subsequent designs. 

[0033] The SBF approach is limited, however, because it does not contain 

strategic design information. While it may provide a model for toilets, instances of 
these models, and state diagrams for the behavior of toilets, there is no processing of 
these models, instances or state diagrams within the SBF knowledge base. The 
processing of this information requires specific programming to investigate and process 
artifact information. 

[0034] Thus, the two knowledge encoding approaches represented by TMK and 

SBF differ in a number of ways. Accordingly, one approach may be more suitable for a 
particular type of knowledge than the other. This suitability influences the selection of 
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a particular approach for a specific type of problem. The TMK language focuses on 
process or strategic knowledge, while the SBF language represents artifact, device, or 
object knowledge. These two types of knowledge are ontologically different, and 
current knowledge systems are generally designed to use either TMK or SBF. 

[0035] Referring now to Fig. 4, a process 400 for combining the TMK and SBF 

approaches is illustrated which allows the solution of problems which benefit from the 
application of both TMK and SBF knowledge. For example, consider a designer who is 
trying to develop a new toilet design with specific design criteria. The criteria may be 
to use less water, to be quieter or smaller, or may include a new feature such as a full- 
flush or half-flush selection. The designer would have several strategic approaches to 
this new design such as starting from first principles and designing an entirely new 
toilet, modifying an existing toilet design, or starting with a related non-toilet device, 
such as a pump, and then designing the toilet around the pump design. Each of these 
strategic approaches may start as a high-level task, divided into methods, procedures, 
and subtasks. The subtasks may be further divided into methods, procedures, and 
additional subtasks. At some point in each of the approaches, the designer may need 
artifact knowledge that may be unique for each approach. For example, the designer 
may need artifact knowledge such as the design of various valves, pipes, levers, the 
design of existing toilet models, or non-toilet devices which match desired toilet 
functions. The process 400 enables the TMK and SBF approaches to be utilized in a 
coordinated manner. 

[0036] The process 400 begins by defining one or more input parameters (e.g. 

input mappings) in step 414. The input parameters may include such information as 
initial values. Output parameters (e.g., output mappings) that enable desired solution 
values to be specified may also be defined in step 414. A determination is made in step 
416 as to whether the task is to be processed using a TMK method or an SBF behavior. 
This determination may be based on information specifying an initial approach 
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provided when the task was defined in step 414. Alternatively, the initial approach 
may be determined by the examination of other information, such as the input and/ or 
output parameter. 



determines whether there are associated methods in step 418. If there are associated 
methods, then one of the methods is selected in step 420. If there are no associated 
methods, the existence of applicable procedures is determined in step 422. If there are 
one or more applicable procedures, one of the procedures is selected in step 424. If 
there are no applicable methods or procedures, then a choice is made as to whether a 
method or a procedure should be defined in step 426. Depending on the choice made in 
step 426, a procedure may be defined in step 428 by specifying the name and at least 
one defining action of the procedure, or a method may be defined in step 430 by 
specifying the name of the method. The steps 420, 424, 428, and 430 each continue to 
the step 448, which will be described later in greater detail. 

[0038] If it is determined in step 416 that the task is to be processed using an SBF 

behavior, the process 400 continues to step 432, where a check is made to see if an 
applicable SBF model exists. If the SBF model exists, the model is selected in step 434 
and the process 400 proceeds to step 436, where it is determined whether an applicable 
behavior exists for the selected SBF model. If the behavior exists, it is selected in step 
446. If the behavior does not exist, it may be encoded in the SBF model using a TMK 
hierarchy (e.g., recursively defining the method in TMK via the process 400) in step 
444. Returning to the determination made in step 432, if an applicable SBF model does 
not exist, the process 400 continues to step 438, where components and connections may 
be defined for the SBF model. In step 440, a determination is made as to whether the 
desired types of components and connections exist. If the components or connections 
do not exist, then they may be encoded as SBF models in step 442 (as illustrated in 
figure 6) and the SBF model's desired behavior may be encoded using a TMK hierarchy 



[0037] 



If the task is to be processed using a TMK method, the process 400 
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in step 444. If the desired components and connections do exist, the process 400 
continues to step 444, where the SBF model's desired behavior may be encoded using a 
TMK hierarchy. Steps 444 and 446 both proceed to step 448. 

In step 448, the inputs and outputs from the task are mapped to the method or 
procedure, which means that the part of the SBF model that is of interest to the method 
is selected and given a name. More specifically, mapping means assigning SBF objects 
or parts of those objects to the names of the input or output. Accordingly, an input 
named X could be assigned my-SBF-modell.componentl (e.g., X <= my-SBF- 
modell.componentl). In addition, this assignment may come from the method above 
or the subtask preceding the current subtask. In step 450, the conditions are defined for 
when to use the method or procedure. These conditions may also depend on the 
knowledge mapped from the above task. If multiple methods or behaviors for a task 
are known or desired by the user, the process 400 may include a check for this in step 
452 and then return control to step 416 if the answer is affirmative. If there are no 
additional methods or behaviors to solve the task, the methods are ordered for 
processing in step 454. 

After processing a method, a determination is made in step 456 as to whether the 
task is the final task. If not, the process 400 returns to step 414 to process the next task 
or subtask. If the determination is made in step 456 that there are no additional 
subtasks, the user may have the option to go back through the hierarchy and modify 
parameters via step 458. After the modification occurs, the process returns to step 414. 
If the parameters are satisfactory, the process 400 ends. 

[0041] The recursion enabled by the process 400 allows an invoking instance to 

complete as all of the instances which it invoked complete. This continues until all 
invoked instances of the initial instance complete, and the initial instance itself 
completes. Accordingly, the success or failure of the initial task (the initial instance of 
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the process 400) determines if an overall solution has been found. The solution may be 
found using a combination of TMK and SBF approaches for different instances. 



hierarchy 200 of Fig. 2 and the SBF hierarchy 300 of Fig. 3 may be combined as 
illustrated in Fig. 4 to provide an improved knowledge acquisition system wherein a 
solution of an SBF model may be utilized as a method of a TMK strategy. That is, in the 
design of a toilet from first principles for using less water than existing designs, one of 
the methods would be to find a water tank with the desired capacity. The solution to 
this method may entail locating the SBF model for tanks which meet certain capacity 
criteria. The method may also request other criteria, for example, material, dimensions, 
and/ or openings sizes. At some point in the modification of an existing design, the 
TMK method may select existing toilet designs with specific desired criteria. In the 
same way, the TMK strategy for design from non-toilet devices may at some point 
request devices matching desired characteristics. 

[0043] In the current example, the method 214 of the TMK tree 200 of Fig. 2 is to 

modify a current design to provide a solution. As described previously, the method 214 
is associated with a subtask 226 and a method 234. The method 234 may be replaced by 
an SBF artifact, such as the "Fill" element 316 from the behaviors 312 of Fig 3. 
Accordingly, when the method 234 is selected, the associated SBF is solved and the 
output of the SBF becomes the output of the method 234 to be used in subsequent TMK 
processing. More specifically, an output of the "Fill" process may be the amount of 
water needed to fill the tank, which is determined in the SBF processing of one or more 
selected designs. This enables the TMK tree 200 to utilize the benefits provided by the 
SBF hierarchy 300. 

[0044] Referring now to Fig 6, in another embodiment, portions of the TMK 

hierarchy 200 of Fig. 2 and the SBF hierarchy 300 of Fig. 3 may be combined as 
illustrated in Fig. 4 to provide an improved knowledge acquisition system wherein SBF 



[0042] 



Referring now to Fig 5, in one embodiment, portions of the TMK 
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models may call on TMK strategic knowledge as device "behavior". That is, a device 
behavior may be defined in terms of tasks, methods, procedures, and subtasks, and the 
output of such behavior may be determined both by the defined behavior and by the 
initial inputs to the knowledge system. For example, in the design of a toilet using less 
water, the "Fill" behavior 316 of Fig. 3 may call on a strategic solution (TMK) to the 
problem of how much water is used. The TMK solution may call on processing tasks to 
determine information such as the size of pipes (e.g., in the design's current stage), the 
time the valve is open (e.g., based on a timer or the length of a designed lever arm), or 
other strategic processing. 

[0045] In the current example, the "Fill" behavior 316 of Fig. 3 uses the method 

214 of Fig. 2. That is, the method 214 is the task identified as modifying a current toilet 
design, so that when the "Fill" behavior is processed, the results are dependent on the 
state of the modified design. The method 214 may process through the subtask 226 and 
the method 234 to find a solution. Accordingly, to determine the "Fill" behavior, the 
outputs of the modified design may be used. It is noted that the "Fill" behavior may be 
associated with either of the other methods 212 or 216 of Fig. 2, which may provide the 
output of "Fill" for an original design or a non-toilet modification, respectively. 

[0046] Accordingly, the combination of TMK and SBF, by using SBF models as 

methods in TMK hierarchies and using TMK strategies as SBF behaviors, allows the 
definition and solution of problems not addressed by either method alone. The 
combination of TMK and SBF provides a unified and symmetric approach to 
knowledge processing. From within the TMK hierarchy, the designer can incorporate 
all of the power of the SBF approach by including it as a method of a task. Similarly, 
from within the SBF structure of models and instances, the full power of TMK can be 
included as artifact behaviors and functions. Thus, the combination provides what 
neither approach does alone: namely, the combination of strategic and artifact 
knowledge. The designer can start with either SBF or TMK, or start with existing SBF 
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models or existing TMK hierarchies, and then add and include the other form of 
knowledge at the appropriate point. This may be accomplished by declaring a TMK 
method to be the behavior or function of an SBF artifact, or by declaring an SBF state 
diagram to be the method of a TMK hierarchy. 

[0047] Referring now to Fig. 7, in another embodiment, an implementation of a 

knowledge acquisition system may utilize both TMK and SBF knowledge stored in 
relational data base tables. Fig. 7 illustrates an example of a table structure 700 for TMK 
knowledge. Task table entries may include the name and description of the task 
represented, and a reference to an optional comment. The entry may also include an 
optional success condition for the task, as well as a reference to an SBF model (also 
called a "class") for which this task is the function. Accordingly, when an SBF model of 
this class is being solved, the TMK entry for this task is used and processed. 

[0048] The task 710 is related to a method 712 and a procedure 714 using 

TaskMethod 716 and TaskProcedure 718 table entries. For purposes of clarity, although 
it is understood that multiple methods and procedures may exist, only a single method 
712 and a single procedure 714 will be discussed. The table entries contain information 
about the relationship between the task 710 and the procedure 714, or the task 710 and 
the method 712. The information may include the name of the method/ procedure, a 
description, and/ or a comment about the relationship; a condition under which the 
method or procedure may be executed, and if more than one condition is met, the order 
in which they are run; and references to any parent tasks and the child methods for the 
relationship. Thus, when the task 710 is selected, all related methods and procedures 
can be found along with the conditions under which they are run. They may then be 
executed in a specified order. 

[0049] The procedure 718 may include the name, description, and an optional 

comment 720. If the procedure 718 is the behavior of an SBF model, the entry may 
include a reference to that model. The procedure 718 may also include a reference to an 
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action 722 (which may be an algorithm, data base look-up, or some other function) that 
implements the procedure 718. 



comment 720. If the method 712 is the behavior of an SBF model, the entry includes a 
reference to that model. The method 712 may have an associated subtask 724. The 
subtask 724 may have references to its parent method 712 and the task 710 which 
spawned the method 712. The subtask 724 may specify a subtask (not shown) which is 
to be run if the subtask 724 is successful, and a subtask (not shown) which is to be run 
in the case the subtask 724 is unsuccessful. 

[0051] Each of these table entries may have a comment 720 associated. Thus each 

entry has an optional reference to a comment table entry, which entry may include a 
long comment about the related entry. 

[0052] In operation, a knowledge engine starts with the desired task 710 and 

attempts to solve it using the TaskMethod 716 and TaskProcedure 718 to locate the 
associated method 712 and procedure 714. The method 712 may spawn the subtask 724 
to complete its processing, or it may invoke an SBF class to provide the method's 
output. The procedure 714 may call on the action 722 to produce the procedure's 
output, or it may invoke an SBF class to provide the procedure's output. Accordingly, 
the processing of a TMK hierarchy may include the invocation of an SBF class for 
processing for either methods or procedures. 

[0053] Referring now to Fig. 8, an implementation enabling methods and 

procedures to reference an SBF class 810 as described above is illustrated. The SBF class 
810 is implemented through a component 812 and a connection 814. For purposes of 
clarity, although it is understood that multiple components, connections, methods and 
procedures may exist, only a single example of each will be discussed. The table entries 
embodying the component 812 and the connection 814 are used by the SBF knowledge 



[0050] 



The method 712 may include the name, description, and an optional 
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engine to locate instances of a model which satisfy the inputs to the processing. The 
SBF class 810, a method 816, a task 818, and a procedure 810 enable the SBF knowledge 
engine to locate and process a related TMK hierarchy when solving the SBF class 810. 
Generally, in an SBF engine, the function of an artifact is static and coded as data in the 
representation of the instance of the model in the SBF database. When solving SBF, the 
knowledge engine would locate and return instances matching the desired function 
input with the value in the SBF database. In the present embodiment, the function is 
not static, and may be calculated as the output of the processing of a TMK hierarchy. 

[0054] While the preceding description particularly shows and describes one or 

more embodiments, it will be understood by those skilled in the art that various 
changes in form and detail may be made therein without departing from the spirit and 
scope of the present disclosure. For example, it is within the scope of the present 
disclosure to use a plurality of methods, procedures, and other processing techniques to 
provide a solution to a given task. In addition, multiple relationships between TMK 
and SBF information may be utilized in developing a desired solution. Therefore, the 
claims should be interpreted in a broad manner, consistent with the present disclosure. 
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